「ゼロから始めるプロジェクトマネジメント Key Points」というタイトルでClassmethod Odysseyに登壇しました #cm_odyssey

情報システム室の進地＠日比谷です。

今回は弊社20周年の特別なイベントであるClassmethod Odysseyで登壇する内容の共有です。

資料

登壇概要

プロジェクトマネジメント未経験の方も今日から参考にできるKey Pointを抜き出してシェア。クラスメソッドの基幹システムを預かる情報システム室コアシステムチームの実践に即したプロジェクトマネジメント手法もお伝えします。

解説

スライドをみていただけると一目瞭然なのですが、今回の登壇でシェアさせていただいた知見はプロジェクトマネジメントの体系的な知識を解説するようなものではありません。むしろ、PMの経験ゼロでもすぐに試せるノウハウを中心に、実戦で身につけた知見のシェアに重きを置いています。

プロジェクトのために人があるのではなく、人のためにプロジェクトがあるという考え方をベースにデスマーチ回避のために打てる手について参考にしていただければ幸いです。

以下、登壇の見出しだけ列記します。気になるところをスライドで見てみてください。

計画編

• プロジェクト計画書を作る
• スケジュールは確率だと頭に叩き込む
• 不用意に日付は出さない
• 見積とスケジュールはメンバーに出してもらう
• 休暇は当然、バグ治しやリファクタリング、CI/CD環境構築、オペトレも計画に入れておく
• 見せる相手によってスケジュールの粒度は変える
• 設計を一日でも早く行い、レビューを受ける
• QAエンジニアにレビューしてもらう
• お客様の担当者は味方でも、お客様の同僚はそうじゃないかもしれない
• 2ヶ月以上かかる案件は最初からPhase2を用意しておく
• 課題管理表、要求管理表、バグ票を用意する

進行編

• シングルタスクをなるべく維持する
• 急かさない
• 家族の急用を常に優先させる
• バッファのコントロールはメンバーに任せる
• スケジュールに遅れがちなメンバーには小さなタスクから任せる
• 新規要件は工数を3倍にして、扱いを判断する
• 定例Mtgは最小化する
• 進捗ではなく、障害を確認する
• 計画、見積はズレる。重要なのは理由を説明できること

佳境編

• 順序付き一覧表をメンテナンスし続ける
• リリース手順書を早めに作る
• 重要なバグ修正と重要な機能開発ではバグ修正を優先する
• QAエンジニアがNoというならリリースしてはいけない
• メンバーの健康状態に気を配る
• 毎日決まった時間に稼働し、決まった時間に退勤する

ふり返り編

• 必ず打ち上げを行う
• 稼働率の実績値を出す
• Phase2以降で本当に行うべきことを改めて考える